I don't believe that you need to keep much static analysis information, if any at all. However, to support this, you need good configuration management practices.
First, you should be regularly tagging the code in your source code repository. Consider tagging (git, Subversion, ClearCase - most version control systems should support similar functionality) any builds that you do. By tagging crucial builds with a unique identifier (like a build number or timestamp), you can relate things like a particular snapshot of source code to entries in a defect tracking database or static analysis results.
Now that you have tags, you can map static analysis results to specific source code repositories. It's commonly accepted that you shouldn't keep generated code in version control. I would argue that you shouldn't keep anything that can be directly generated from the source code, which includes static analysis. However, for traceability purposes, you will need to be able to associate defects derived from static analysis to the build that caused the finding.
Realistically, you may want to keep some static analysis results. For example, the results of analysis prior to an external release may be included as part of a formal test report. Even if it isn't part of a test report, you may want to keep this in a project archive. You may also consider including a static analysis summary (such as number of findings, number of findings per source line of code, number of findings by module, number of findings by criticality, or number of findings by type).
You may also want to consider how you manage your static analysis tool, especially if you are using it as part of some kind of formal testing or report. You need to be able to consider the version of the tool as well as the configuration file or parameters used when executing the tool over a given version of the code base. If you don't manage your tool version and configuration, it becomes harder to be able to regenerate the exact same report for a given code base.