Sonar, a provider of code scanning tools, revealed this week that it has discovered a flaw in a widely used tool for generating application programming interfaces (APIs) that makes it possible for cybercriminals to both read and delete files and files stored in a write directory.
The OpenAPI Generator is an open-source project that enables developers to automatically generate API client libraries, server stubs, documentation and configurations using the OpenAPI specification, formally known as Swagger.
The OpenAPI Generator community has provided a patch to resolve the issue, but there may be developers who have yet to upgrade their instance of the tool. Additionally, there may be thousands of APIs that have been created using previous versions of the tools that DevSecOps teams should find, review and, most likely, update. The issue affects versions 7.5.0 of the OpenAPI Generator and below.
Stefan Schiller, a vulnerability researcher for Sonar, said these OpenAPI source code vulnerabilities can be especially difficult to detect because they are not easily detected within complex processes. Sonar, for example, used taint analysis tools that enabled it to track data from its source to its ultimate use, also known as Sink, to discover this vulnerability.
Of course, now that this vulnerability has been disclosed DevSecOps teams working for organizations that are using OpenAPI Generator are now in a race to remediate a known vulnerability.
It’s also probable that DevSecOps teams are going to encounter multiple similar issues as organizations increasingly rely on tools that automatically generate code, noted Schiller. The more removed developers are from how code is being created the less likely it is they might spot an issue, he noted.
Making matters more challenging still, vulnerabilities involving open-source code might not be addressed for weeks by the maintainers of the project. Depending on the level of complexity of the issue, that might take weeks or even months for a patch to be made available. Then it’s up to the DevSecOps teams to ensure that no developers are still using an outdated version of that open-source software.
Hopefully, with the rise of AI it will become easier to not only discover and remediate vulnerabilities but determine when inherently flawed tools are being used to write code. DevSecOps, after all, is as much about changing the internal culture of an application development team as much as it is simply ensuring that developers have the tools they need to scan code.
In the meantime, DevSecOps teams should assume that much of the code running in existing production environments is likely to be deeply flawed in an era where cybercriminals now routinely scan applications for vulnerabilities. It’s not feasible to replace all that code overnight with clean code but the more often code is updated the more secure applications should steadily become. The challenge, of course, is prioritizing those update efforts based on the actual level of risk a vulnerability represents to the business at a time when even with the help of AI only so much code can be written, tested and deployed on any given day.
