Dependabot reporting on deleted files

[davidpustai]

1. I've committed a package.json with a library subdirectory included in my project (not using package manager for this project).
2. Dependabot reported a security alert.
3. I've deleted the package.json and thought that it would resolve it.

But I'm still getting the alert listed in my daily e-mail notification (and in the list of alerts on repository Security page). I've tried to dismiss the alert with "A fix has already been started", didn't change anything.

The alert page further shows a warning message "Dependabot cannot update this dependency" detailed as "Dependabot couldn't update this dependency to the required version as it doesn't support your dependency files.".

[sambdavidson]

+1 bump

[davidpustai]

Hm. Not sure if fixed and resolved, I've dismissed the alert before so cannot check now, but it is no longer reported in my weekly report.

[rob4629]

Similar situation. I was investigating a couple of libraries, but deleted them a few months ago... randomly started getting security alerts for them 🤷‍♂

[carlgunderson]

I have a repo that used to be an Angular project with a yarn.lock file. That file was deleted from the repo several months ago. But I continuously get security alerts from dependencies that were referenced in the yarn.lock.

The dependencies do not exist and that file does not exist.

Clicking the filename link does nothing.

[lopopolo]

I converted some repos from yarn.lock to package-lock.json and I only get Github Security Advisories for the long-since deleted yarn.lock file. It is unclear if the existing package-lock.json file is monitored.

[levenleven]

I have monorepo and deleted one of the packages. But still getting alerts once a while (until dismissed) for no longer existing package-lock.json

[christopherblaser]

Getting this as well from a long since deleted yarn.lock file.

[karlhorky]

I'm also being affected by this (I deleted a package-lock.json file a long time ago), but:

• not just about old security notifications (I am also getting new security notifications)
• not just notifications over email - they also show up in the GitHub notifications list

Here's an example (I've marked this as "This alert is inaccurate or incorrect"): https://github.com/karlhorky/talks/network/alert/packages/2017-11-01-react-open-source-the-effect-of-react-on-web-standards/package-lock.json/elliptic/closed

@davidpustai can you update the title and description to be more general regarding the points above? It's about Dependabot reporting on deleted files in all ways, which is a bug and shouldn't happen.

[WereDev]

I too am having this issue. The files it's reporting have been deleted for months. Even the folders that they used to be in are long gone.

[rlisowski]

The same for me. File and directory have been deleted a while ago but I still get new notifications about vulnerabilities.

[rande]

Did you have a branch with those deps still available ?

[WereDev]

Did you have a branch with those deps still available ?

In my case, no. There are only two branches and the files were completely removed from both. I haven't checked it in a while as all I was getting was false reports so I disabled the feature.

[liddellj]

I also recently experienced this - received an alert against a package.json file that had been deleted from the master branch weeks ago. Clicking the link to the package.json in the alert resulted in a 404. We do have stale branches that will still include that package, but my understanding was that dependabot should only pay attention to the default branch.

[wigsofoz]

We had this issue today (GitHub Enterprise 2.22.4).

A workaround -

1. Replace the deleted package.json file with one that has zero dependencies. Commit it.
2. Delete the package.json file. Commit it.

The result of this is the zeroing out of the Dependency Graph for that file, but the file remains mentioned in the dependency graph view. You shouldn't get any more security warnings for those outdated dependencies.

[jurre]

I know the Dependency Graph team is aware of this, I'll link them to this thread

[tomwillis608]

+1 I have a project where a deleted Pipfile.lock keeps getting vulnerability findings, even though the file was deleted on all branches months ago.

[raniesantos]

I have a similar problem.

I stopped using Yarn, but my security alerts indicate that dependabot is still reading from yarn.lock.

At the moment running npm audit locally shows 0 vulnerabilities.

Please give us some way to manually force dependabot to recognize the new lock file.

[jurre]

The Dependency Graph team fixed an issue with deleted manifests a while ago, these issues might pre-date the fix? If you let me know the repo this is happening on I can force a re-detect, or feel free to contact support and they should be able to do it as well.

Unfortunately there is currently no way to run the re-detect yourself, and (possibly confusingly) our team doesn't maintain this feature, but I'm happy to help and so are our wonderful support engineers.

[raniesantos]

@jurre

https://github.com/raniesantos/artisan-static

[raniesantos]

@jurre is the link enough or should I also contact support like you said? Where can I do this?

[jurre]

Hi @raniesantos, I just kicked off the re-detection. I was out for a few days over Easter hence the slow response.

FWIW support can be contacted via https://support.github.com/

[ccrraaiigg]

I also need a re-detect, on repo https://github.com/ccrraaiigg/caffeine/. Thanks!

[sarahbeverton]

My group gets frequent dependabot alerts for a long ago deleted package-lock file. Do I need a re-detect or is there any other way to solve this? Yesterday I added, then removed, an empty package-lock in place of where the file used to be. That seemed to get rid of the alerts from yesterday, but the deleted file is still listed in the dependency graph, and we all got yet another email dependabot alert for the file today.

[raniesantos]

I'm still getting this, I just got it this week.

[johnslipper]

@jurre I also would like a re-detect for https://github.com/johnslipper/smb3-memory-card-game/ if possible?

[donatj]

We moved our package.json / package-lock.json up a level over a year ago, it was in public/js/app and is now in public/js but we still get warnings for the old public/js/app.

When you click into one of these even Dependabot is like "something is wrong here"

[raniesantos]

I got an email alert about my non-existent yarn.lock file again today.

[2-REC]

We had this issue today (GitHub Enterprise 2.22.4).

A workaround -

1. Replace the deleted package.json file with one that has zero dependencies. Commit it.
2. Delete the package.json file. Commit it.

The result of this is the zeroing out of the Dependency Graph for that file, but the file remains mentioned in the dependency graph view. You shouldn't get any more security warnings for those outdated dependencies.

Just had the issue (on a previously existing 'package.json' deleted a while ago). This workaround seems to have solved it.

[raniesantos]

Can you please seriously consider giving repo owners more direct control over this?

I thought my issue would have been solved already, but it just came back.

[grzesuav]

I got the same, I get alerts for Gemfile.lock which does not exist....

[BinBashBanana]

Happening to me too... super annoying

[tegner]

It makes very little sense that the alert is sent week upon week, while the file is actually missing. And marked as inaccurate every week.

[jurre]

Hey, I know it's somewhat confusing but dependabot-core is not used for the alerts feature on GitHub. This issue is on that teams radar though, so I'm going to close this out from our issue tracker. When running into this the easiest way to reach that team is to go via github support, but we'll try to forward things as best as we can.

[chadlwilson]

Acknowledging that this might not be a dependabot issue - has anyone figured out how to address this when the Dependency Graph is showing previously deleted vendored dependencies, e.g historically source controlled Ruby gems and gemspecs?

According to https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/troubleshooting-the-dependency-graph it's not supposed to look at vendored deps anyway (for whatever reason).

e.g. it wasn't doing so until recently, but https://github.com/gocd/gocd/network/dependencies has started showing stuff long-since deleted e.g

Deleted in https://github.com/gocd/gocd/commit/f8132a1e8f9e1ebf58c1f188f247fdfa6a032e40.

Since the source is not a single Gemfile or GemFile.lock I'm not sure what workaround might exist here. Tried adding an empty folder with .gitkeep but didn't seem to do the trick. Will try raising a ticket with Github Support, but thought someone might have noticed this and figured this one out.

(Edit: Asking support to clear and redetect dependencies for the repo via a Support Ticket seemed to remove these. Took about 24 hours turnaround. No word on the root cause or whether it's a bug to be considering vendored dependencies just yet)

[jeffwidman]

You could also try creating a Code Security discussion... that's the officially recommended "public" place for raising issues about dependency graph or security alerts. But based on your description, this may be specific to your repo in which case a support ticket is probably your best bet.

[chadlwilson]

Thanks @jeffwidman - will see how I get on with support and try the community otherwise. Reason I asked is that this seems to have started in the last few days around the time of the launch of the new Dependency Graph view, and the behaviour contradicts documentation so is at least a documentation bug, if not a "real" bug - usually such things affect multiple folks.

No idea if the original bug discussed here on inexplicably stale dependency graph entries has been addressed - maybe it hasn't been and some recent changes to include vendored dependencies (which seems reasonable to me, personally) has just exposed some repos with similar issues.

[jorisroling]

Just had this issue with a old yarn.lock file pointing to since than long remove package. (this commit is actaully already three year old). Since then I moved from yarn.lock to package-lock.json.

I fixed my issue by adding a new yarn.lock file (by running 'yarn'). commited this. Then deleted to yarn.lock file again, and commit this again. Looking at the alert page (pointed to in the mail), this immediately 'removed' the issue.

Hope this helps some of us. Cheers!

[jl2]

I'm still seeing this in some of my repos. Very, very annoying to get these emails for fixed issues, so I'm disabling the dependabot scan.

[chadlwilson]

I'm still seeing this in some of my repos. Very, very annoying to get these emails for fixed issues, so I'm disabling the dependabot scan.

You can use the virtual agent to ask GitHub to redetect dependencies for a repo. Try this search?

[domschl]

While that virtual agent is a nice high-tech work-around (can't say yet if it actually does something), but how about solving the underlying problem?

I am (so far) receiving Rust dependency errors for a Python project that doesn't contain a single line of Rust in any branch any more. That indicates that Dependabot uses some hallucinated project state as basis for it's reports which is a twofold security issue in itself:

• It might miss actual problems because reporting on some outdated state
• It will make users annoyed because of reporting hallucinated problems, making them switch off an otherwise very useful tool.

So, Github, please fix the underlying issue.

[chadlwilson]

@domschl Based on https://github.com/dependabot/dependabot-core/issues/2041#issuecomment-979953683 I think the issue here is that it relates to some problematic caching or something else outside dependabot itself so we'd need to find the right place to get this tracked on GitHub side of things if it's still happening, either via GH support or some other repo?