Dependabot powers Dependabot security updates, which allow GitHub users to automatically update vulnerable dependencies. The core logic of Dependabot is open-source and an overview of the architecture is available.
dependabot-coreThe dependency update jobs are designed to execute arbitrary code. Update jobs run in a sandbox designed to execute untrusted code and prevent access to private networked resources or other users’ data. Escaping the sandbox to access private networked resources or other user’s data is a vulnerability and eligible for reward.
This is the most common ineligible Dependabot report we receive. A manifest, lockfile, or build script that runs your code during an update job is doing exactly what the job is for. The finding starts at the sandbox boundary. Your report needs to show something concrete on the other side of it, such as reaching an internal host, reading another customer’s data, or obtaining credentials that outlive the job. Proof that your code ran, that you can see the container filesystem, or that you have network access to the public internet is not a sandbox escape.
Dependabot acts on the repository that enabled it, using permissions that repository granted. Opening pull requests, reading the dependency graph, and writing to a branch it created are intended. Reports that someone who can already push to the repository can influence a Dependabot run are ineligible.
Findings in third party packages, or in advisories published about them, belong to those maintainers. Report them to the package owner or through the GitHub Advisory Database. Reports that Dependabot did not alert on a given package, alerted late, or scored an advisory differently to another source are ineligible.