3 ms·

Hot take; they don't use their security alerts to manage dependency vulnerabilities. Sorry, taking this on a tangent but the security alerts feature as integra

by Rapzid 5y ago

Hot take; they don't use their security alerts to manage dependency vulnerabilities. Sorry, taking this on a tangent but the security alerts feature as integrated into the product is WAY less usable than other features, such as actions. Just off the top of my head: * No way to assign alerts to people * No free-form comments when dismissing alerts? * Old alerts re-open if a regression introduces the change back.. With no history on the alert to see why an "opened 6 months ago" alerts suddenly appeared * Alerts that can't have PR fixes opened because "The vulnerable package is no longer used"(paraphrasing) are still open.. Why? Such a lackluster area of the product it has me wanting to give Snyk(blarghh) another look or some other alternatives.

danpalmer 5y ago
I haven't used the security alerts, but isn't the idea that you open an issue and then track it there using the regular project management tools? > Snyk(blarghh) What's wrong with Snyk?
- asciimike 5y ago
  That's how everyone does it today, but given that GitHub has an issues product, it really should be better integrated. The main issue is that issues are publicly viewable, while security alerts are only available to certain users (e.g. repo admins). Since repo owners of e.g. popular OSS repos might not want public issues around their security vulnerabilities, this isn't something that's been actioned. Should GitHub offer more granular permissions on issues to resolve this? Probably, but unfortunately that's reaching fairly deep into how GitHub works today. (Disclosure: former Dependabot PM, no longer at GitHub)
asciimike 5y ago
I don't think it's too hot a take, but it is incorrect. Dependabot Alerts (and Updates) are required on all internal services and folks use them (and provide similar feedback). Dependabot Alerts is working on some of these things, starting with e.g. https://github.blog/changelog/2022-02-08-dependabot-alerts-persisted-after-fix-now-one-per-advisory/ https://github.blog/changelog/2022-02-08-dependabot-alerts-p... I know that security alerts in general are working on ways of assigning alerts (or opening issues that reference those alerts)--hopefully this is something that will show up soon. (Disclosure: former Dependabot PM, no longer work at GitHub)
- lloydatkinson 5y ago
  Do you know why a repo might be getting dependabot alerts when it used to have them setup, but now it doesn't, yet still gets them randomly?
  - asciimike 5y ago
    Hate to say it but have you tried turning it on and off again? IIRC sometimes the state of alerts got stuck in a weird place and resulted in the incorrect state. Toggling it might put it back into the desired state. I'd also check and make sure Updates is turned off (delete the dependabot.yml).
    - lloydatkinson 5y ago
      Well there's no yml file at all which is the confusing part but I suppose I could try make a blank one
havs 5y ago
(Disclosure: current PM for Dependabot Alerts, currently working at GitHub) You're right -- we haven't invested nearly enough in Dependabot Alerts. We're working to change that, starting with some foundational improvements like alert persistence, which shipped in February. (https://github.blog/2022-02-08-improving-developer-experience-dependabot-alerts/ https://github.blog/2022-02-08-improving-developer-experienc...) After our recent ship, we're in good shape to start addressing some of your concerns, like greater clarity through an alert's lifecycle or comments with dismissal. Would love to hear any additional feedback. Let me know!

by Rapzid 5y ago

danpalmer 5y ago

I haven't used the security alerts, but isn't the idea that you open an issue and then track it there using the regular project management tools? > Snyk(blarghh) What's wrong with Snyk?

asciimike 5y ago
That's how everyone does it today, but given that GitHub has an issues product, it really should be better integrated. The main issue is that issues are publicly viewable, while security alerts are only available to certain users (e.g. repo admins). Since repo owners of e.g. popular OSS repos might not want public issues around their security vulnerabilities, this isn't something that's been actioned. Should GitHub offer more granular permissions on issues to resolve this? Probably, but unfortunately that's reaching fairly deep into how GitHub works today. (Disclosure: former Dependabot PM, no longer at GitHub)

asciimike 5y ago

I don't think it's too hot a take, but it is incorrect. Dependabot Alerts (and Updates) are required on all internal services and folks use them (and provide similar feedback). Dependabot Alerts is working on some of these things, starting with e.g. https://github.blog/changelog/2022-02-08-dependabot-alerts-persisted-after-fix-now-one-per-advisory/ https://github.blog/changelog/2022-02-08-dependabot-alerts-p... I know that security alerts in general are working on ways of assigning alerts (or opening issues that reference those alerts)--hopefully this is something that will show up soon. (Disclosure: former Dependabot PM, no longer work at GitHub)

lloydatkinson 5y ago
Do you know why a repo might be getting dependabot alerts when it used to have them setup, but now it doesn't, yet still gets them randomly?
- asciimike 5y ago
  Hate to say it but have you tried turning it on and off again? IIRC sometimes the state of alerts got stuck in a weird place and resulted in the incorrect state. Toggling it might put it back into the desired state. I'd also check and make sure Updates is turned off (delete the dependabot.yml).
  - lloydatkinson 5y ago
    Well there's no yml file at all which is the confusing part but I suppose I could try make a blank one

havs 5y ago

(Disclosure: current PM for Dependabot Alerts, currently working at GitHub) You're right -- we haven't invested nearly enough in Dependabot Alerts. We're working to change that, starting with some foundational improvements like alert persistence, which shipped in February. (https://github.blog/2022-02-08-improving-developer-experience-dependabot-alerts/ https://github.blog/2022-02-08-improving-developer-experienc...) After our recent ship, we're in good shape to start addressing some of your concerns, like greater clarity through an alert's lifecycle or comments with dismissal. Would love to hear any additional feedback. Let me know!