# Is there native support for OpenAPI (openapi.yaml) analysis in SonarQube Cloud?

**URL:** <https://community.sonarsource.com/t/is-there-native-support-for-openapi-openapi-yaml-analysis-in-sonarqube-cloud/151580>\
**Category:** SonarQube Cloud\
**Tags:** api, yaml\
**Created:** [October 29, 2025, 8:53pm UTC](https://community.sonarsource.com/t/is-there-native-support-for-openapi-openapi-yaml-analysis-in-sonarqube-cloud/151580 "2025-10-29T20:53:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![csantillan](https://avatars.discourse-cdn.com/v4/letter/c/2bfe46/32.png) [@csantillan](https://community.sonarsource.com/u/csantillan)\
**Post date:** [October 29, 2025, 8:53pm UTC](https://community.sonarsource.com/t/is-there-native-support-for-openapi-openapi-yaml-analysis-in-sonarqube-cloud/151580/1 "2025-10-29T20:53:01Z")

</div>

Hi community,

We are using SonarQube Cloud and have a specific question about analyzing our API specification files.

In our repositories, we have `openapi.yaml` files alongside our source code (e.g., `apiproxy`). I’ve noticed that while the source code is analyzed correctly, the `openapi.yaml` file itself doesn’t seem to be scanned for OpenAPI-specific vulnerabilities, design bugs, or code smells.

 ![openapi](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/3X/a/b/ab1a7cb8d9ce60b10078c5456fbe6996a2a6ab70.png)

 ![sonarqubecloud](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/3X/d/f/df46dcfefd76aaf65e3e22cbac1a06a23e78eaf3.png)

I know that on self-hosted **SonarQube Server** (Community/Data Center) versions, it’s possible to install third-party plugins (like the `sonar-openapi-plugin`) which add these rules and analyze the API specification in depth.

Since we cannot install custom plugins on **SonarQube Cloud** , my question is:

1. Has **native** support for analyzing OpenAPI specification files (YAML or JSON) been added to SonarQube Cloud recently?

2. If it’s not native, what is the official or SonarSource-recommended way to achieve this analysis in SonarQube Cloud?

I have read that one possible solution is to use an external linter (like **Spectral** ) in our CI/CD pipeline, generate a report in the “Generic Issue Data” format, and then import it into SonarQube Cloud using the `sonar.externalIssuesReportPaths` property.

Is this still the only recommended approach, or is there a more integrated solution available now or planned for the future?

Thank you for your guidance.

Best regards.

---

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [October 31, 2025, 8:53am UTC](https://community.sonarsource.com/t/is-there-native-support-for-openapi-openapi-yaml-analysis-in-sonarqube-cloud/151580/2 "2025-10-31T08:53:24Z")

</div>

Hey there.

This is not supported today – you can vote for it [here](https://portal.productboard.com/sonarsource/1-sonarqube-cloud/c/421-openapi-support?&utm_medium=social&utm_source=share).

So in the meantime, your only option would be to import external issues as you mentioned. 🙂