_**:information_source: Please Note:** This epic documents work toward deprecations and removals that are targeted for %15.0 within the [Static Analysis group](https://about.gitlab.com/handbook/product/categories/#static-analysis-group)._ _For current details of what deprecations are currently announced for Static Analysis, and all of GitLab, see [Deprecations by Milestone](https://docs.gitlab.com/ee/update/deprecations) in product documentation. Static Analysis [deprecation issues](https://about.gitlab.com/handbook/product/gitlab-the-product/#process-for-deprecating-and-removing-a-feature) for 15.0 are in &7698._ ----------- # Overall considerations The strategy here could be summarized as "get what we can do done to improve our velocity in the coming year". Other items that _don't_ speak to this goal are included in [14.8 Planning](https://gitlab.com/gitlab-org/gitlab/-/issues/350213). (14.8 is our last available release in which to announce 15.0 deprecations.) It is completely OK—even expected—that refinement or investigation could lead to us figuring out that we can't expect to finish certain items. And while we should try to be as confident as we can, it's an acceptable risk to announce a pending 15.0 deprecation and then not finish it by 15.0. We shouldn't do this too much, but a miss or two would still be a good balance between customer confusion and ability to cut as much overhead as we can in 15.0. This is meant to [balance](https://about.gitlab.com/handbook/values/#hierarchy) iteration and results gains against possible transparency loss. # Current priorities - https://gitlab.com/gitlab-org/gitlab/-/issues/350935+ | Deprecation Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/352553 - .NET is currently a weak point and we see large customers with large amounts of it. It also seems to have become more common in [recent survey research](https://www.jetbrains.com/lp/devecosystem-2021/). Prioritizing the experience for more up-to-date versions compared to 2.1 makes the out-of-the-box experience better for forward-thinking orgs. - Note other security-code-scan/.NET-related items in https://gitlab.com/gitlab-org/gitlab/-/issues/350213+. But these aren't deprecations so they aren't in this epic. - Image distribution changes | Deprecation Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/352564 - Reasoning: completing the image location change helps advance a cross-functional effort. - Issue: [Location of Static Analysis images](https://gitlab.com/groups/gitlab-org/-/epics/6162) - https://gitlab.com/gitlab-org/gitlab/-/issues/334325, specifically. - Audit for analyzers emiting JSON schemas older than 14.0: https://gitlab.com/gitlab-org/gitlab/-/issues/350814+ | No deprecation issue - Semgrep transition: Investigation into whether we can break the dependency on TI fingerprinting for https://gitlab.com/groups/gitlab-org/-/epics/7201#note_809862322. | Deprecation Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/352554 - If we could, for instance, have semgrep "impersonate" the other analyzers when issuing findings by assuming their vulnerability source identifier, perhaps we could unblock ourselves and reduce the number of analyzers we need to support, maintain, convert to UBI8 base, etc. - This is for investigation, ideally first as a source code review before more time-consuming testing/analysis. If we figure out we're still blocked, at least we're not in a worse place than before. - [Update default spotbugs java version from 8 to latest LTS (17)](https://gitlab.com/gitlab-org/gitlab/-/issues/347067) | Deprecation Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/352549 - Seems like a common request, and it's never great to have a security product make you jump through hoops to use the latest version of languages and other dependencies. In fact we want to advise this precise practice (https://gitlab.com/gitlab-com/legal-and-compliance/-/issues/729)—awkward if we don't then make it easy to do so. - Noted below, we do need to figure out what data we can use to determine whether to drop older versions or just add newer versions. The documentation language in [the linked issue](https://gitlab.com/gitlab-com/legal-and-compliance/-/issues/729) would indicate that our general practice is not to support old versions. And by 15.0 we'd be out of the public release period for Java 8, according to discussion below. # Best-case items - https://gitlab.com/gitlab-org/gitlab/-/issues/217668+ | Deprecation issue: necessary? - Based on the discussion below, it's not 100% clear if this would be a deprecation. We also could use more data on how common this setup is and currently don't have that data at hand (or at least I don't–@connorgilbert). - Completion of https://gitlab.com/gitlab-org/gitlab/-/issues/339812+ | No longer required; see https://gitlab.com/gitlab-org/gitlab/-/issues/350814 - GitLeaks deprecations (https://gitlab.com/gitlab-org/gitlab/-/issues/350660) | Deprecation issue: https://gitlab.com/gitlab-org/gitlab/-/issues/352565 - Seems like a relatively small customer impact and an improvement to maintainability - https://gitlab.com/gitlab-org/gitlab/-/issues/350573+ | Deprecation issue: https://gitlab.com/gitlab-org/gitlab/-/issues/352565 - Announce in 14.8, execute in 15.0 # Not currently prioritized - [Aligning the image tag scheme for Code Quality with other analyzers](https://gitlab.com/groups/gitlab-org/-/epics/7201#note_808832411) | Not planned - Code Quality currently uses a version scheme that aligns with the upstream Code Climate project. This scheme differs from the SAST analyzers. - https://gitlab.com/groups/gitlab-org/-/epics/4060 | Not planned - Deemed no longer needed for 15.0. - Previous reasoning for prioritization: - We expect these changes to reduce risk and make the release cycle more understandable. (It seems customers sometimes don't expect analyzers to be updated outside of GitLab releases.) - And, this would align the offline experience closer to SaaS—to address a risk identified in &4060, already we could have customers running new analyzers on old versions in such environments if new analyzers aren't pulled. - Completing both updates in the same cycle may mean we don't have to bother folks again in 16.0. - [Kubesec to the IaC template](https://gitlab.com/groups/gitlab-org/-/epics/6655#note_700863136) | Not planned - _Could_ be promoted with additional analysis of usage. - Today, customers have the ability to choose one approach or the other today, which seems an acceptable situation. Kubesec doesn't seem like the hardest dependency to maintain, as well. - Currently, `kubesec` has reasonably high usage. Given low ongoing carrying costs and issues with kics, we do not need to push this deprecation. # Discussion notes for individual items ## Upgrades to analyzers - https://gitlab.com/gitlab-org/gitlab/-/issues/350935+ - .NET 2.1. It's an LTS version that has reached end of life. https://dotnet.microsoft.com/download/dotnet - Update Security Code Scan to the latest version to enable .NET 5/6 scanning https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/95480/diffs#f96be1e6344935e269994d6b8df200a2546a7504_0_14 - Full major version behind the latest and greatest OSS project; v3 of the GitLab security-code-scan analyzer is released and available opt-in, but isn't the default now. Getting to v3 of the analyzer gives you .NET 6 and VS 2019+ support. Work is done, we understand the scope here to be updating the default version in the vendored template. - Known risk: we don't know exactly how many people use .NET 2. We can get a general idea but could make improvements to the data fields we collect to get a better sense of usage on .com. - .NET 4.0 has come up a lot from field and isn't supported in GitLab today (many 4.x versions are past EOL and Microsoft doesn't readily provide binaries anymore) - We may be able to address this type of need with a documented before_script, or find a way to get out of compilation (which would mean something like moving to semgrep) - We don't want to _encourage_ people pinning to the old version, but we don't pull them down, so that's an option. - [Kubesec to the IaC template](https://gitlab.com/groups/gitlab-org/-/epics/6655#note_700863136) - This is about moving Kubesec from SAST template to SAST IaC. Haven't made progress on the discussion to decide whether to deprecate kubesec entirely. - Consequences of moving: - Anyone using IaC today might get Kubesec by surprise unless we add a config - Customers who want to keep using Kubesec would have to include the IaC template - If people were trying to migrate from Kubesec to kics we'd have the downstream mapping issue - [Update default spotbugs java version from 8 to latest LTS (17)](https://gitlab.com/gitlab-org/gitlab/-/issues/347067) - Drop 8 or just add 17? - Spotbugs is our most complex analyzer and needs to compile. It has Java 8 and 12 now but folks have been requesting 13, 14, 15, 17, ... Question is whether we drop 8 or just add 17 and bloat the image. Larger image sizes = higher registry costs. Currently something like 1.2GB compressed. Java 8 end of free public updates is March 2022, extended support available through 2030. - Precompilation strategy is supported; someone could disable our precompilation and run a before_script to generate JARs, as an alternative. - Don't know precisely which Java versions are getting invoked. ## Replacement of analyzers - Analyzer deprecations for semgrep (https://gitlab.com/groups/gitlab-org/-/epics/7201#note_809862322) - We have rulepacks for Python, GoLang, JS, TS, C; so, we could potentially deprecate Bandit, GoSec, eslint, and part of flawfinder. - The benefit is maintaining fewer dependencies and having greater control over rulepacks. Also a duplication benefit: if we run eslint and semgrep with rules that duplicate each other, currently we de-duplicate them downstream. - The costs include the Threat Insights issue related to tracking individual findings. Essentially, the downstream vuln management system doesn't understand how to handle when the detection mechanism for an individual reported vulnerability changes; it's an (understandable) abstraction mismatch. That's a prereq unless we want the findings to be orphaned and recreated. There's a group of identifiers for a finding, and one is primary; a secondary one might be a CWE or something. Thiago and Thomas are going to revisit some of this soon. Note that addressing this problem could also help folks migrate different scanners to GitLab, as long as the identifiers are present. - We don't necessarily need to solve this problem today, but we do need to decide if we are comfortable announcing the deprecation without the plan in place. As a descriptive statement, this is a tightly coupled system and this constraint is why we wouldn't feel comfortable just deprecating right now. - Known risk: slight coverage decrease. For example, GoSec is at ~98% replacement; we've migrated everything semgrep supports, in general. May want to follow up with VR. ## Other changes - https://gitlab.com/gitlab-org/gitlab/-/issues/217668+ - Pipelines can be triggered on different events (e.g. code pushes, MR opens). Security is triggered on code pushes. If someone has an MR pipeline configured, they have to override in awkward ways to get security scans to work. - Thomas: Wouldn't characterize this as a deprecation or removal, philosophically. The implementation we choose would determine this. - Persistent sticking point; not supporting this particular configuration is a top articulated blocker for dogfooding. We're not sure. - https://gitlab.com/gitlab-org/gitlab/-/issues/339812+ - Consideration: whether analyzers all act the same. If we go our own way and other analyzer teams don't, then SAST will act differently. - In 15.0, TI is dropping support for older versions of schemas; we need to do an audit to make sure that all of our analyzers produce supported versions. The audit shouldn't take a ton of time to complete, but could lead to work if deficiencies are identified. - Definitely need to: audit - May need to: fix - Could: add other fields, which would help get better data to Sisense - Note: linked issue is a proposal, not finalized; may need refinement before continuing - https://gitlab.com/groups/gitlab-org/-/epics/4060+ ## Distribution changes - [Location of Static Analysis images](https://gitlab.com/gitlab-org/gitlab/-/issues/336372) - Important to close out - Characterized as a deprecation because the location would change and would affect people pulling images into other environments. However, it would be easier for them after the change. - See open issues in https://gitlab.com/groups/gitlab-org/-/epics/6162 # Notes - [Deprecations and removal notification process](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes ).