Document language/framework versions supported in SAST
Problem to solve
When adopting SAST, users seem to frequently fall into cases where they're using language or framework versions that either:
- aren't supported
- require workarounds or customizations to support
For example, .NET 4 often comes up in support tickets and it's not easy to discover from documentation alone that there are known issues with support for this version.
As another example, .NET 6 support was released in 14.6 but required opt-in until 15.0. That led a number of customers to run into issues trying to use it in the meantime (see #360734 (closed) and linked Zendesk ticket). Had we documented the steps in the supported-versions table, we could have prevented this confusion.
Similarly, the SpotBugs analyzer only supports certain Java versions out of the box, but you can add certain customizations or adopt the pre-compilation strategy to provide artifacts and skip the compilation step, which is sensitive to the Java version.
We would make it both clearer to users (Transparency) and more efficient for Support and other stakeholders (Efficiency) if we could clearly document the boundaries of what we support out-of-the-box, plus any recommended customizations like pre-compilation that address gaps in out-of-the-box support.
Proposal
SAST: Supported Languages and Frameworks seems like a natural spot for this. However, we currently only list a minimum supported GitLab version; if we were to list versions, we might need to add version numbers (or analyzer versions?) for each language/framework version.
One option—although it could get unwieldy—would be to add footnotes for table rows where we know the language is very important (say, Java and .NET?), similar to the approach taken in !77799 (merged). Then, we could move on from there as the need arises, and adopt a new approach if we discover one is needed.
Who can address the issue
If there's any disagreement or subtlety to the approach, Technical Writing and any other interested parties should weigh in.
It would be particularly useful for those who have dealt with the lack of this information to weigh in on what would be most useful to include in an initial change—@greg comes to mind.
Once we agree on an approach, we would likely need to gather version information from the Static Analysis team or from the documentation that exists for each analyzer.
Other links/references
There are many related support tickets and issues. Here are a few.
JDK versions:
.NET version 4:
- Issues related to Security Code Scan support for .NET 4.x (#350913 - closed)