Hacker News Reader

Comment by Rapzid | Hacker News Reader

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.

View on HN

(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-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!

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-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)

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?

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).

Well there's no yml file at all which is the confusing part but I suppose I could try make a blank one

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?

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)

Reply on news.ycombinator.com