14 open vulnerabilities (8 High, 5 Moderate, 1 Low) + 2 leaked secrets

[harshach]

This ticket is initially opened by @mars-lan, which was accidentally deleted. Here is the image for reference

Affected module Does it impact the UI, backend or Ingestion Framework?

Describe the bug https://metaphor.io/blog/is-open-source-software-more-secure) for additional context

To Reproduce

1. Fork the repo
2. Turn on Dependency graph & Dependabot alerts in Code security and analysis
3. View the alerts under Security tab

Expected behavior 0 vulnerability & 0 leaked secret

[harshach]

Hi @mars-lan,

Thanks for filing the issue and bringing this up. I want to take a moment to address the concerns raised, especially around the security of OpenMetadata, and to highlight a few key points about the advantages of open-source software in general.

Open Source vs. Closed Source Security

There’s a common misconception that open-source software is less secure than closed-source software. Actually, open source often has the edge when it comes to security. With projects like OpenMetadata, the code is out in the open—meaning it’s constantly reviewed by developers, security experts, and users all over the world. This level of scrutiny leads to faster identification and fixing of vulnerabilities compared to closed-source software, where only a small internal team typically reviews the code.

Keeping code hidden doesn’t inherently make it more secure—it just means fewer eyes are on it. Closed-source software can leave vulnerabilities unnoticed for long periods, whereas open-source projects benefit from the transparency and speed of the community. With so many people actively involved, issues get flagged and resolved much more quickly.

OpenMetadata Security Practices

Disclosure Policy We follow a responsible disclosure policy, which you can find here: Responsible Disclosure Policy. Moving forward, please use this channel for reporting any potential security vulnerabilities to ensure they’re addressed quickly and appropriately.

Automated Scanning OpenMetadata undergoes daily scans via GitHub and twice-weekly scans via Snyk to identify vulnerabilities, whether in our code or containers. This is part of our ongoing effort to keep everything secure and up-to-date.

Secure Releases All of our images are scanned to ensure zero vulnerabilities at the time of release.

On the Specific Issues Raised

It looks like the issues mentioned in your blog post might be based on an outdated version of OpenMetadata. Please ensure you’ve pulled the latest main branch or the most recent release when reviewing.

Secrets in the Repo: This claim doesn’t hold up with our current main or any recent release branches. We do not have any secrets checked into the repo.

UI Dependency Vulnerabilities: Most of the UI dependency vulnerabilities have already been addressed. However, in cases where third-party libraries are involved, we’re still working on it. We don’t always control when those third-party libraries push their updates, but rest assured, we’re on it.

Open Source Strength

One of the great things about open source is the transparency. Anyone can inspect the code, identify vulnerabilities, and contribute fixes. With open-source projects like OpenMetadata, we get feedback from researchers and users across hundreds of different organizations, helping us stay ahead of potential issues. This level of community involvement and oversight is a huge advantage over closed-source software, where security flaws can go unnoticed simply because fewer people are looking.

Thanks again for your feedback. We’re always open to more collaboration and appreciate the engagement from the community. Looking forward to continuing to work together to make OpenMetadata better and more secure.

[mars-lan]

Thank you for the thorough reply. This is much better than the Acryl team, which hasn't responded my issue for 3+ days.

Here are a few follow-ups:

Clear text secrets

These were indeed secrets (case 1, cast 2) committed to the repo several years ago. I can confirm that both credentials are no longer valid. Unfortunately, git never forgets so they got picked up by GitHub's scanner:

Vulnerabilities from third-party

It's understandably more complex to resolve transitive vulnerabilities resulting from third-party libraries, but that's the very definition of software supply chain security. There are established ways and best practices that can be adopted here.

Responsible Disclosure Policy

We're fairly familiar with how this works, given that we created and open-sourced DataHub. However, I don't believe it applies in this case, as the vulnerabilities are all well known and highlighted by GitHub's dependabot already. Anyone who forked this repo would have direct access to the list.

Open Source vs. Closed Source Security

The real point of my blog post wasn't about whether OSS is more or less secure inherently, but that it ultimately boils down to the team behind the project. In this very example, some of the vulnerabilities are known for 90+ days. I highly suspect that if it were not the post, they'll continue to be ignored for another while.

[harshach]

Hi @mars-lan,

Thanks for your follow-up. I want to clarify a few things based on your points.

Clear Text Secrets

Yes, there were historical secrets in the repo several years ago, which were rendered invalid a long time ago. While we understand that GitHub’s scanner picked them up, let’s be clear: these credentials are completely irrelevant now and do not pose any ongoing risk. Now that you agree that this is not a risk, we will appreciate if you can issue a edit to your blog on clarifying the stance

Third-Party Vulnerabilities

You’re correct that transitive vulnerabilities are part of the software supply chain security landscape. However, managing dependencies in an open-source project requires a careful balance. While best practices exist, third-party libraries can sometimes be slow to update, and we do not control their timelines. That said, we are actively improving how we handle these issues, but let’s not overlook the fact that some delays are beyond our immediate control. We are committed to securing OpenMetadata, but there are inherent complexities in supply chain security that apply to all software, not just this project.

Responsible Disclosure Policy

While I respect your familiarity with responsible disclosure, the policy is there for a reason. If your intention was to raise awareness of already-known vulnerabilities, we appreciate that. However, GitHub’s dependabot scans are publicly visible to any fork of the repo—so these aren’t exactly hidden issues. It’s worth noting that simply posting known vulnerabilities without going through proper channels doesn’t necessarily help move things forward any faster.

Open Source and Team Responsiveness

Regarding your comment about our responsiveness: We take security seriously. It’s worth noting that many of the libraries flagged by GitHub’s scans are not even used at runtime—they’re development dependencies or transitive ones. For each flagged vulnerability, we document where it’s used and how it impacts the project, if at all, as part of our ongoing vulnerability scans.

Claiming that these vulnerabilities would have been ignored without your post is quite a stretch. We continuously monitor and work on these issues. Your feedback is appreciated, but it doesn’t singularly dictate the project’s direction. Security is dynamic, and our team is committed to ensuring OpenMetadata remains secure through constant improvements, regardless of external prompts.

In conclusion

While we value constructive feedback, it’s clear that this conversation isn’t solely about helping improve OpenMetadata. We recognize that you are involved with a competitive, closed-source product, and we understand the underlying motivation to draw attention. That said, we are committed to staying focused on facts and transparency. OpenMetadata is driven by a global community, and we hold ourselves accountable to rigorous standards—not to drive-by critiques aimed at gaining attention.

We will continue to prioritize security, document our practices, and engage with those who are genuinely interested in improving the project. We welcome meaningful collaboration, but we won’t be distracted by attempts to undermine our work. Open-source thrives on openness and collaboration, not on spreading doubt for competitive advantage.

[mars-lan]

Clear Text Secrets

I've edited Is Open-Source Software More Secure? to clarify the false positive.

Responsible Disclosure Policy

Let's agree to disagree here. However, I'd like to reiterate the fact (see below) that no one seems to be paying attention to these already-known/publicly visible issues. Without my public disclosure, they'll most likely continue to get ignored for years to come.

Open Source and Team Responsiveness

I understand your team's desire to take security seriously. Sadly, this doesn't quite match up to the reality. As far as I can tell, there are at least 3 HIGH vulnerabilities that have been published for more than 2 months (one is as old as nearly 2 years!):

• https://github.com/advisories/GHSA-36jr-mh4h-2g58 (published 9/29/2022)
• https://nvd.nist.gov/vuln/detail/CVE-2024-4068 (published 5/14/2024)
• https://nvd.nist.gov/vuln/detail/CVE-2024-37890 (published 6/17/2024)

Note that these vulnerabilities impact the main product, not just the dev tools.

It could be that dependabot had a serious bug and never raised these issues until recently. If so, please post a screenshot of the Dependabot Alerts page from the official branch, which should show the original dates these alerts were first raised.