Using GitHub Dependabot for your eSTAR SBOM: a practical guide (and where it falls short).

If your code lives on GitHub, someone on your team has probably already asked the question: "We've got Dependabot running, can't we just use that for the SBOM?"

I have used Dependabot for this purpose. The honest answer is: it gets you part of the way there, and for some teams it is a sensible starting point. But there are pitfalls that are not obvious until you are deep into your eSTAR submission, and by then the cost of discovering them is measured in weeks, not hours.

This post walks through what Dependabot actually gives you, how to use it, and the specific places where it will quietly let you down.

What Dependabot actually gives you

Two things are worth separating here, because they are often conflated.

GitHub's dependency graph analyses your repository and builds a map of every package your project depends on. You can export this as an SBOM. That is a GitHub platform feature, not a Dependabot feature, though they share the same underlying dependency data.

Dependabot alerts monitor those dependencies against the GitHub Advisory Database and notify you when a known vulnerability (a CVE, or Common Vulnerabilities and Exposures identifier) affects something in your project. It can also open pull requests to update vulnerable packages automatically.

Both are free on all GitHub plans. Both are genuinely useful for development hygiene. If you are building a medical device and your code is on GitHub, you should have Dependabot enabled regardless of what else you use.

Credit where it is due: for common package ecosystems, Dependabot catches real issues and automates the tedious work of keeping dependencies current. It is one of the better free security tools available to any development team, and the fact that it is built into GitHub means the barrier to adoption is essentially zero.

The question is not whether Dependabot is useful. It is. The question is whether it produces everything the FDA needs to see in your eSTAR submission, or whether you need to supplement it.

Exporting an SBOM from GitHub

GitHub can export an SBOM directly from the dependency graph. Navigate to your repository, click Insights, then Dependency graph, and you will find an Export SBOM option. This produces an SPDX-format JSON file listing your project's dependencies.

You can also do this via the API or GitHub CLI, which is more practical if you want to automate it as part of your release process.

The export captures components that GitHub can detect through your manifest files: package.json, requirements.txt, go.mod, pom.xml, and the other supported ecosystems. For those ecosystems, the data is generally accurate. Component names, versions, and dependency relationships are pulled directly from the package manager metadata.

This is your starting point. What follows are the reasons it is only a starting point.

Pitfall 1: It only sees what the package manager sees

This is where things get consequential for medical devices.

Dependabot and GitHub's dependency graph analyse your manifest files. If a component is declared in package.json or requirements.txt, it will appear in the SBOM. If it is not, it will not.

For a typical web application, that coverage is reasonable. For a medical device, it often is not.

Embedded firmware written in C or C++ typically has no package manager. Third-party libraries are added by copying source files into the repository or linking precompiled binaries. Vendor-provided HALs (hardware abstraction layers), RTOSes (real-time operating systems), and cryptographic libraries all fall into this category. Dependabot has no idea they exist.

Container images present a similar gap. If your device includes a containerised component, the operating system packages inside that container (openssl, libc, zlib) are invisible to Dependabot. It can update your Docker base image tag, but it cannot scan the image contents for vulnerabilities.

The result is an SBOM that looks complete but is missing your highest-risk components. Firmware and OS-level libraries are where the critical CVEs tend to live. An SBOM that omits them is not just incomplete. It creates a false sense of security that can undermine your entire submission.

If your device architecture includes embedded firmware, container images, or third-party vendor components, you will need to supplement the GitHub export with manual documentation or additional tooling.

Pitfall 2: No NTIA minimum element validation

The FDA references the NTIA (National Telecommunications and Information Administration) minimum elements for SBOMs. These define the fields your SBOM must include: supplier name, component name, version, unique identifier, dependency relationship, author of SBOM data, and timestamp.

GitHub exports an SBOM. Nobody checks whether it meets these requirements.

In practice, GitHub's exports are reasonably good on component names and versions. They are less reliable on supplier names and unique identifiers (particularly CPE, or Common Platform Enumeration identifiers, which are used for matching against the NVD). Some components will have complete metadata. Others will have gaps.

The problem is that you will not know about those gaps unless you explicitly validate the output. Missing supplier names or absent PURLs (Package URLs, the identifier format used for matching components to vulnerability databases) will not cause an error during export. They will cause questions during review.

The kind of questions that lead to an RTA (Refuse to Accept), the FDA's way of sending your submission back before it even reaches a reviewer's desk. An RTA for something that could have been caught with a validation step before submission is, to put it mildly, an expensive way to learn about NTIA compliance.

Pitfall 3: Default branch only

This is the one that catches most medical device teams by surprise.

Dependabot security alerts only run against the default branch of your repository. For a cloud service that deploys continuously from main, this makes perfect sense. There is one version in production, and it is whatever is on the default branch.

Medical devices do not work this way.

You may have v1.2, v1.3, and v2.0 all actively deployed in hospitals simultaneously. When a new CVE is disclosed in a library you depend on, you need to know which versions are affected. Not just the current development branch. Every version still in the field.

Dependabot cannot tell you. It monitors one branch. Your post-market surveillance obligations cover every version you have shipped and still support.

This is not a minor limitation for the purpose of regulatory compliance. IEC 62304 and the FDA's cybersecurity guidance both expect ongoing monitoring of fielded products. If your monitoring strategy relies solely on Dependabot, you have a blind spot that covers your entire release history.

The workaround is to maintain separate SBOMs for each release version and monitor them independently. Dependabot will not do this for you.

Pitfall 4: Dismissed alerts still need documenting

When Dependabot flags a vulnerability, you can dismiss the alert with a predefined reason: "fix started," "tolerable risk," "inaccurate," or "no bandwidth." That is useful for keeping your alert queue clean during development. But dismissing an alert in GitHub is not the same as documenting it for your eSTAR submission.

Every dismissed vulnerability that remains in your shipped product needs to appear in your cybersecurity risk file. The eSTAR cybersecurity section requires a documented risk assessment for known vulnerabilities. The most common approach is the MITRE CVSS (Common Vulnerability Scoring System) rubric, though it is not the only option. Whichever method you use, reviewers expect to see a severity score, your assessment of exploitability in the context of your device, any mitigations you have implemented, and the residual risk after those mitigations.

This is perfectly doable. You can maintain a cybersecurity risk spreadsheet alongside your Dependabot alerts and use the spreadsheet version of the MITRE CVSS rubric to score each one. For every dismissed alert, you save the calculated rubric with commentary explaining why the residual risk is acceptable. The key is traceability: every dismissed Dependabot alert needs to map to an entry in your cybersecurity risk file with supporting documentation.

Where teams run into trouble is organisation. If you are disciplined about tracing every alert from Dependabot through to the risk file from day one, it works. If you leave it until submission time and try to reconstruct the rationale for dozens of dismissed alerts retroactively, it becomes painful. The volume of alerts in a typical medical device project means this process benefits from being systematic rather than ad hoc.

Pitfall 5: No eSTAR-format output

Even if you resolve every issue above (supplement the SBOM with manual components, validate NTIA elements, monitor multiple versions, and document proper risk assessments), you still need to produce the actual documentation in the format the FDA expects.

Dependabot gives you data. It does not give you documents.

The eSTAR cybersecurity section expects structured documentation: the SBOM itself, a vulnerability assessment with CVSS scoring, evidence of ongoing monitoring capability, and supporting narratives. Assembling this from Dependabot output, NVD data, and your own risk assessments means building a documentation pipeline from scratch.

Some teams manage this with spreadsheets and word templates. It works, but it is fragile. A new vulnerability disclosed the week before submission means repeating the entire exercise. A version mismatch between your SBOM and your vulnerability assessment means explaining the discrepancy to a reviewer.

Making it work: a pragmatic approach

None of this means you should disable Dependabot. Quite the opposite. Keep it running. It is genuinely good at what it does: catching known vulnerabilities during development, automating dependency updates, and keeping your codebase current. For development hygiene, it is one of the best tools available, and it costs nothing.

But recognise what it is: a development tool, not a regulatory documentation tool.

For the eSTAR submission itself, you need to fill the gaps: ecosystem coverage beyond what GitHub supports, NTIA validation, multi-version monitoring, structured risk assessment, and formatted output. You can build this pipeline yourself from open source components and manual processes. Some teams do, and it works, though it takes time and discipline to maintain.

This is also why I built Threat Detective. It handles the regulatory documentation side: SBOM validation, vulnerability scanning across all ecosystems (including C/C++, container images, and vendor SBOMs), CVSS risk scoring using the MITRE rubric, and eSTAR-format output. Your team can focus on building the device rather than building a compliance pipeline. If you want to see the specific differences, the comparison page breaks it down feature by feature.

The bottom line

Dependabot is a genuinely good development tool. It is not a regulatory documentation tool. Those are different jobs, and understanding the boundary between them is how you avoid surprises at submission time.

Know what Dependabot gives you. Know where the gaps are. Plan for them before you are three days from your eSTAR submission deadline and discovering that your SBOM is missing half your firmware components.

Your cybersecurity documentation should not be the reason your submission gets sent back.